home *** CD-ROM | disk | FTP | other *** search
-
-
- Essential Tools for the OSI Internet
-
-
- Network Working Group IETF-NOOP Working Group
- INTERNET DRAFT S. Hares, C. Wittbrodt
-
-
-
-
- 1. Status
-
- This document is an Internet Draft. Internet Drafts are
- working documents of the Internet Engineering Task Force
- (IETF), its Areas, and its Working Groups. Note that other
- groups may also distribute working documents as Internet
- Drafts.
-
- Internet Drafts are draft documents valid for a maximum of
- six months. Internet Drafts may be updated, replaced, or
- obsoleted by other documents at any time. It is not
- appropriate to use Internet Drafts as reference material or
- to cite them other than as a "working draft" or "work in
- progress."
-
- Please check the I-D abstract listing contained in each
- Internet Draft directory to learn the current status of this
- or any other Internet Draft.
-
- This Internet Draft specifies tools which are necessary to
- debug problems in the deployment and maintenance of networks
- using ISO 8473[1], the connectionless network layer protocol
- (CLNP). This document will be submitted to the RFC editor as
- a proposed standard for the OSI Internet.
-
- To support some of the needed tools (ping and traceroute)
- this draft specifies the mechanism specified in RFC1139 [3].
-
-
- 2. Abstract
-
- This document specifies the following three necessary tools
- to debug problems in the deployment and maintenance of net-
- works using ISO 8473 (CLNP):
-
- - ping or ISO Echo function
- - traceroute function which uses the ISO Echo function
- - routing table dump function
-
-
- These CLNS tools are the basics required for hosts and
- routers for CLNS network support. It is intended that this
- document specify the most basic support level required for
- CLNS hosts and routers.
-
- This document should progress along the IETF track for host
- and router requirements.
-
-
- March 23, 1993 Expires September 23, 1993 Page 1
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
- 3. Table of Contents
-
- Section 1 Status ...................................... 1
- Section 2 Abstract .................................... 1
- Section 3 Table of Contents ........................... 2
- Section 4 Conventions ................................. 2
- Section 5 Introduction ................................ 2
- Section 6 Specification ............................... 3
- Section 6.1 Ping ...................................... 3
- Section 6.1.1 Protocol Support ........................ 3
- Section 6.1.2 Functions supported by the ping utili-
- ty ............................................... 4
- Section 6.2 Traceroute ................................ 4
- Section 6.2.1 Basic Traceroute ........................ 4
- Section 6.2.2 Use of Partial Source route in tra-
- ceroute .......................................... 6
- Section 6.2.3 Information needed from a Traceroute
- utility .......................................... 7
- Section 6.3 OSI routing table dump .................... 7
- Section 6.4 MIB variables available via SNMP .......... 8
- Section 6.4.1 Summary of MIB Variables ................ 8
- Section 6.4.2 ASN.1 Syntax for these MIB variables .... 8
- Section 7 ISO HOST.txt format ......................... 11
- Section 8 Acknowledgements ............................ 12
- Section 9 Author's Addresses .......................... 12
- Section 10 References ................................. 14
-
-
- 4. Conventions
-
- The following language conventions are used in the items of
- specification in this document:
-
- o MUST, SHALL, or MANDATORY -- the item is an absolute
- requirement of the specification.
-
- o SHOULD or RECOMMENDED -- the item should generally be followed
- for all but exceptional circumstances.
-
- o MAY or OPTIONAL -- the item is truly optional and may be
- followed or ignored according to the needs of the implementor.
-
-
- 5. Introduction
-
- Currently in the Internet, OSI protocols are being used more
- and more. As the network managers of an Internet once
- predominantly a TCP/IP network began deploying parts of the
- emerging OSI Internet, it became apparent that network layer
- ISO network debugging tools were almost nonexistent. When
- such tools existed, different implementations didn't work
- together.
-
-
-
- March 23, 1993 Expires September 23, 1993 Page 2
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
- As stated in RFC 1139 a simple network layer mechanism is
- necessary to allow systems to be probed to test network
- layer integrity. For the purposes of running OSI networks
- the authors of this document believe that other tools are
- necessary too. Other tools described below are an echo
- function, a traceroute function, and a routing table dump.
- What this document defines is the minimum subset of tools
- that are necessary to allow for the debugging of network
- problems.
-
-
- 6. Specification
-
- This document's purpose is to specify a standard ping, tra-
- ceroute, and OSI routing table dumping mechanisms for use
- for the ISO 8473 (CLNP) protocol in the OSI Internet. A
- detailed description of the specified mechanisms is below.
- These mechanism MUST be available on every router (inter-
- mediate system) or host (end system) that provides OSI ser-
- vice for the Internet. These three functions are the basic
- tool set for the OSI network layer for the Internet.
-
-
- 6.1. Ping
-
- 6.1.1. Protocol Support
-
- The long term echo mechanism, as described in RFC1139,
- requires the use of two new type values in the packet header
- of the ISO 8473 Network Protocol Data Units(NPDUs), or
- preferably packets. The two values are:
-
-
- 1E(hex) - for the Echo Request Selector and,
- 1F(hex) - for the Echo Reply Selector.
-
-
- Nodes which support ISO8473 but do not support these two new
- values (for the type code option field in the header of an
- ISO 8473 packet) MUST send back an error packet IF the ERROR
- report flag is set in the packet.
-
- To support a ping function for ISO 8473, all end systems
- (hosts) and intermediate systems (routers) MUST support the
- "long term" echo function as defined by RFC 1139-Revised AND
- also set the ERROR report flag in the 8473 header.
-
- The setting of the ERROR report flag is required because
- this allows a way for a compliant host or router to ping a
- non-compliant host or router. When a non-complaint host or
- router receives a "ping" packet with the new type function
- (Echo Request Selector), it MUST attempt to return an ISO
- 8473 error packet to the originating host, thus showing
-
-
- March 23, 1993 Expires September 23, 1993 Page 3
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
- reachability.
-
-
- 6.1.2. Functions supported by the ping utility
-
- A ping utility MUST be able to provide the Round trip time
- of each packet, plus the average minimum and maximum RTT
- over several ping packets. When an error packet is received
- by the node, the ping utility MUST report the error code to
- the user.
-
-
- 6.2. Traceroute
-
- The CLNP trace is similar to the ping utility except that it
- utilizes the "Lifetime" field in the ISO 8473 packet. Hosts
- and routers that support OSI MUST also support CLNP trace.
- The "Lifetime" field serves the same function as the Time To
- Live (TTL) field does in an IP packet. A node (router or
- host) cannot forward ISO 8473 packet with a value for the
- Lifetime of zero. If the ERROR REPORT flag is set in the
- ISO 8473 packet, an error packet, will be returned to the
- originator of the packet.
-
-
- 6.2.1. Basic Traceroute
-
- If a ISO 8473 echo-request packet is sent with "Lifetime"
- field value of 1, the first hop node (router or end system)
- will return an error packet to the originator the packet.
- If the first hop node supports the echo-request type field
- the error code will be either:
-
-
- A0 (hex) - Lifetime Expired while Data Unit in Transit
- A1 (hex) - Lifetime Expired during Re-assembly
-
-
- If the first hop node does not support echo-request type
- field, the error code will be:
-
-
- B0 (hex) - Unsupported Option not Specified.
-
-
- When trying to trace a route to a remote node, the destina-
- tion address in the echo-request packet sent should be this
- remote destination. By using increasing values in the
- "Lifetime" field a route can be traced through the network
- to the remote node. This traceroute function should be
- implemented on each system (host or router) to allow a user
- to trace a network path to a remote host or router.
-
-
-
- March 23, 1993 Expires September 23, 1993 Page 4
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
- The error message is used as evidence of the reachability
- and identity of the first hop. The originator then sends a
- packet with a "lifetime" field value of 2. The first hop
- decrements the "Lifetime" and because the "Lifetime" is
- still greater than 0, it forwards it on. The second hop
- decrements the "Lifetime" field value and sends an error
- packet (ER NPDU) with one of the two "Lifetime Expired"
- error codes listed above to the originator. This sequence
- is repeated until either:
-
-
- - the remote host is reached an either an echo-reply packet is sent
- back or (for nodes that do not have the required Echo support)
- an error packet is sent back, or
-
- - the an error packet is received with error code (B0) indicating
- that a node will not pass the Echo-Reply packet, or
-
- - an error packet is received with one of the following errors:
-
- 80(hex) - Destination Address Unreachable
- 81(hex) - Destination Address Unknown.
-
-
- If any of the following Error codes are received in an error
- packet, a second packet should be sent by the originating
- node:
-
-
-
- CodeReason from 8473
- -----------------------------
- 00(hex) - Reason not specified
- 01(hex) - Protocol procedure error
- 02(hex) - Incorrect checksum
- 03(hex) - Packet Discarded due to Congestion
- 04(hex) - Header Syntax Error (cannot be parsed)
- 05(hex) - Segmentation needed but not permitted
- 06(hex) - Incomplete packet received
- 07(hex) - Duplicate Option
- B1(hex) - Unsupported Protocol Version
- B2(hex) - Unsupported Security Option
- B3(hex) - Unsupported Source Routeing Option
- B4(hex) - Unsupported Recording of Route Option
- C0(hex) - Reassembly Interface
-
-
- If one of these error is detected, an error value should be
- returned to the user. More than one echo packet, may be
- sent at a "Lifetime" value. The number of additional echo
- packets is left up to the implementation of this traceroute
- function.
-
-
-
- March 23, 1993 Expires September 23, 1993 Page 5
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
- If one of the following errors is received, AND "partial
- source route" is not specified in the echo-request packets,
- send a second echo-request packet to the destination at a
- "Lifetime" value:
-
-
- Code Reason from 8473
- --------------------------------
- 90(hex) Unspecified Source Routeing Error
- 91(hex) Syntax Error in Source Routeing Field
- 92(hex) Unknown Address in Source Routeing Field
- 93(hex) Path not Acceptable
-
-
- (The echo-request packet may have been damaged while
- traversing through the network.)
-
-
- 6.2.2. Use of Partial Source route in traceroute
-
- The current IP traceroute has a 3rd party or "loose source
- route" function. The ISO 8473 protocol also supports a
- "partial source routeing" function. However, if a node
- (router or host) does not support the "partial source route-
- ing" function an ISO 8473 packet gets passed along the path
- "exactly as though the function has not been selected. The
- packet shall not be discarded for this reason."[2]
-
- In order utilize the partial source route function in the
- ISO traceroute, a node must set the "source routeing" option
- and "partial source routeing" parameter within that option.
- A 3rd party, or "loose source route" traceroute function
- requires that a node send an echo-request packet with the
- "loose source routeing" field set. The functioning of the
- 3rd party/"loose source route" traceroute is the same except
- the following errors cause the traceroute to be terminated:
-
-
- Code Reason from ISO 8473
- --------------------------------------------------
- 92 Unknown Address in Source Routeing Field
- 93 Path not Acceptable
-
-
- These errors may indicate a problem with the "loose source
- route" listed in the echo-request packet for this destina-
- tion. Additional packets with the same lifetime will only
- repeat this error. These errors should be reported to the
- user of the traceroute function.
-
-
-
-
-
-
- March 23, 1993 Expires September 23, 1993 Page 6
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
- 6.2.3. Information needed from a Traceroute utility
-
- A traceroute utility should provide the following informa-
- tion to the user:
-
-
- - the identity of systems that comprise the path or route
- to the destination (the identifiers are called Network
- Entity Titles or NETs in OSI and ISO 8473)
-
- - ping times (in Round trip times) for each
- hop in the path,
-
- - error codes from error packet received as a
- response to the an echo-request packet, and
-
- - any other error conditions encountered
- by traceroute.
-
-
-
- 6.3. OSI routing table dump
-
- Each OSI host (end system) or router (intermediate system)
- MUST be able to dump any of its routing tables. Routing
- tables may come from the:
-
-
- a.) the ES-IS information
- b.) static
- c.) IS-IS
- d.) IDRP
-
- or any other source.
-
-
- Each system MUST be able to dump the routing table entries
- via some out of band mechanism. A method MUST exist to pro-
- vide these. A show osi routes command SHOULD be created with
- the following options:
-
-
- - a for all routes
- - esis for es-is routes
- - isis for is-is routes
- - idrp for idrp routes
- - static for static routes
- - other for routes from other sources.
-
-
- In addition, routing tables SHOULD be available via either
- SNMP or CMIP. The specification of CMIP variables are out-
- side the scope of this specification. Section 6.4 specifies
-
-
- March 23, 1993 Expires September 23, 1993 Page 7
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
- the RFC 1238 MIB variables which MUST be available via SNMP.
- These two variables simply allow the user to get some basic
- CLNS routing information.
-
- Please note that not all the information requested is avail-
- able via the CLNS MIB. Due to this fact, it is anticipated
- that additional work on a CLNS MIB will be done in the
- future. When a new MIB is written, it is anticipated that
- this document will be updated to include the additional MIB
- variables to collect such things as the ES-IS cache.
-
-
- 6.4. MIB variables available via SNMP
-
- The Simple Network Management Protocol [cf] plays an impor-
- tant role in monitoring of multi-protocol, managed resources
- in the Internet. By convention, SNMP is mapped onto User
- Datagram Protocol (UDP, cf); however, in those situations
- where it is not possible to communicate with an ISO 8473
- managed resource using SNMP over UDP, or where communication
- with an ISO 8473 managed resource using SNMP/UDP is not
- possible/appropriate, SNMP messages should be mapped onto an
- OSI transport (cf) The following Managed Objects for the
- SNMP must/should/may be supported to facilitate remote moni-
- toring using the SNMP:
-
- The Simple Network Management Protocol (SNMP) plays an
- important role in monitoring of multi-protocol, managed
- resources in the Internet. By convention, SNMP is mapped
- onto User Datagram Protocol (UDP); however in those situa-
- tions where it is not possible to communicate with an ISO
- 8473 managed resource using SNMP over UDP, or where communi-
- cation with an ISO 8473 managed resource using SNMP/UDP is
- not possible/appropriate, SNMP should be mapped onto an OSI
- tranport (TP4 reference). It is RECOMMENDED that the fol-
- lowing Managed Objects be supported for remoted monitoring
- using SNMP:
-
-
- 6.4.1. Summary of MIB Variables
-
- RFC 1238 CLNS MIB[5]
-
- 1) clnpAddrTable - Addresses for Interfaces
- 2) clnpRoutingTable - ISO routes in system routing table.
-
-
-
- 6.4.2. ASN.1 Syntax for these MIB variables
-
- The ASN.1 sytnax for the two variables the MIB in CLNS MIB
- (RFC 1238) is included below for easy reference. Both these
- RFCs remain the authoritative source for the MIB
-
-
- March 23, 1993 Expires September 23, 1993 Page 8
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
- definitions.
-
-
- 1) clnpAddrTable
-
- clnpAddrTable OBJECT-TYPE
- object.id = .... {clnp 21 } (Dave what do I put here??)
-
-
- clnpAddrTable = SEQUENCE OF ClnpAddrEntry
- CLNPAddrEntry ::= SEQUENCE {
- clnpAdEntAddr
- CLNPAddres,
- clnpAdEntIfIndex,
- INTEGER,
- clnpAdEntReasmMaxSize
- INTEGER (0...65535);
- }
-
- clnpAdEntAddr = ClnpAddress
- clnpAddress = OCTET string (Size (1...20);
- clnpAdEntIfIndex = INTEGER;
- clnpAdEntReasmMaxSize = INTEGER (0...65535); #
-
- Descriptions of Table entry values:
-
- clnpAdEntAddr - CLNP address for this interface value
- clnpAdEntIfIndex - Interface Index value corresponding to
- IfIndex value.
- clnpAdEntReasmMaxSize = Maximum size of a pdu that can be
- reassembled from incoming PDUs
- received on this interface.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- March 23, 1993 Expires September 23, 1993 Page 9
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
- 2) clnpRoutingTable
-
- object id =....{clnp 22}
- clnpRoutingTable = SEQUENCE OF ClnpRouteEntry;
- ClnpRouteEntry = SEQUENCE OF {
- clnpRouteDest,
- clnpRouteIfIndex,
- clnpRouteMetric1,
- clnpRouteMetric2,
- clnpRouteMetric3,
- clnpRouteNextHop,
- clnpRouteType,
- clnpRouteProto,
- clnpRouteAge,
- clnpRouteInfo}
-
- clnpRoutDest ::= ClnpAddress; # Address in Route table (prefix or
- # full address
- clnpRouteIfIndex ::= Integer; # IfIndex value for interface
- # next hop can be reached through.
- clnpRouteMetric1 ::= Integer; # primary routing metric for this
- # protocol. Specific meaning
- # depends on clnpRouteProto value
- # -1 if not used
- clnpRouteMetric2 ::= Integer; # alternate routing metric for this
- # protocol. Specific meaning
- # depends on clnpRouteProto value
- # -1 if not used
- clnpRouteMetric3 ::= Integer; # alternate routing metric for this
- # protocol. Specific meaning
- # depends on clnpRouteProto value
- # -1 if not used
- clnpRouteMetric4::= Integer; # alternate routing metric for this
- # protocol. Specific meaning
- # depends on clnpRouteProto value
- # -1 if not used
- clnpRouteNextHop::= ClnpAddress; # Address of Next Hop in Routing
- # Table
- clnpRouteType::=INTEGER {
- other (1), # none of following
- invalid (2), # an invalid route
- direct(3), # a direct route
- remote(4)} # a remote route
-
- clnprouteProto::= INTEGER {
- other (1), # none of the following
- # (manually configured
- # falls in this category)
- local(2), # configured entries
- netmngt(3), # set via Network management
- is-is(9), # ISO 10589
- ciscoIgrp(11), # Ciscos OSI IGRP
- ospf(13), # OSPF set
-
-
- March 23, 1993 Expires September 23, 1993 Page 10
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
- bgp(14), # BGP sets
- idrp(15) # addition suggested to rfc 1238
- # in processing
- clnpRouteMetric5::= Integer; # alternate routing metric for this
- # protocol. Specific meaning
- # depends on clnpRouteProto value
- # -1 if not used
- clnpRouteInfo ::= OBJECT-ID; # protocol id that
- # installed this route
- }
-
-
-
- 7. ISO HOST.txt format
-
- The OSI format for addresses allows addresses to be 20
- bytes. In the long term, a Directory service (DNS service
- or OSI Directory service (X.500)), will provide a host name
- to address mapping. The process of getting OSI capable DNS
- and Directory service may require OSI pathway to already be
- set-up. Most host and router system use a fixed table to
- provide this name to NSAP address mapping in order to get
- OSI working on their system. The current operational problem
- is each implementation has a different format. This docu-
- ment defines a fixed format so that these initial name to
- NSAP mapping files can be shared through-out the internet.
-
- To conform to this document, a host or router supporting
- CLNS MUST have support a "osi host.txt" file with the format
- below. The "osi host.txt" file may be used for other OSI
- applications or TUBA applications. For these other applica-
- tions, other fields may be defined but the definition of
- these is outside the scope of this specification.
-
- OSI applications may use another file name for osi address
- information. We strongly RECOMMEND that NSAP addresses in
- any osi address information use the format below. This host
- name to NSAP mapping MUST BE available for use by the fol-
- lowing utilities on CLNS hosts and routers:
-
- - ISO Echo (Ping) function,
- - ISO traceroute function, and
- - router table look-up for CLNS
- routing information
-
- We RECOMMEND that host and router systems also support a
- NSAP to name mapping by the Domain Name Service Directory or
- or the OSI Directory service (X.500).
-
-
-
-
-
-
-
- March 23, 1993 Expires September 23, 1993 Page 11
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
- Format of osi hosts file:
-
- <NSAP Address> <name1> <name2> ...<name>
-
-
- The NSAP Address should be in the following format:
-
- <first octet>.<2nd octet 3rd octet>.<4th octet 5 octet>.
- ..... <18th octet> <19th octet> .<20th octet>
-
-
-
- comments on the above format:
-
- The NSAP octets should be expressed in hexidecimal. The dots
- are aids to help read the NSAP address, and not required for
- an NSAP address parsing. However, each NSAP address file
- MUST be able to have the ability to handle the insertion of
- dots.
-
-
- An example of this use in the GOSIP format is:
-
- 47.0005.80ff.ff00.0000.0001.0001.0a0b.0c0d.0204.00
-
- An example of this format in ANSI format is:
-
- 39.480f.8000.0500.0000.0001.0001.0a0b0c0d.0204.00
-
- This value quickly shows the AFI and the NSEL octets on either end.
-
- <name1> <name2> <name> - Indicates a sequence of name associated with
- this nsap address.
-
-
-
- 8. Acknowledgements
-
- The authors would like to acknowledge the contributions made
- by Dave Piscitello. He not only kept the document accurate,
- but also helped us to get rid of the ISO jargon and make the
- document more readable. Thanks to Paulina Knibbe for her
- work with the host.txt format. We would also like to thank
- members of the Network OSI Operations Working Group of the
- IETF for their comments.
-
-
- 9. Author's Addresses
-
-
-
-
-
-
-
- March 23, 1993 Expires September 23, 1993 Page 12
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
-
- Susan K. Hares
- MERIT/NSFNET
- Internet Engineering
- 1075 Beal Avenue
- Ann Arbor, MI 48109-2112
- (313) 936-3000
-
-
- Cathy J. Wittbrodt
- Stanford University/BARRNet
- Networking Systems
- Pine Hall 115
- Stanford, CA 94305
- (415) 725-5481
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- March 23, 1993 Expires September 23, 1993 Page 13
-
-
-
-
-
-
-
- Essential Tools for the OSI Internet
-
-
- 10. References
-
- [1] ISO/IEC 8473, Information Processing Systems, "Protocol
- for Providing the Connectionless-mode Network Service and
- Provision of Underlying Service". May, 1987.
-
- [2] R. Hagens, "An Echo Function for ISO 8473", Request For
- Comment #1139, January 1990. DDN Network Information
- Center, SRI International.
-
- [3] S.Hares and C.Wittbrodt, "An Echo Function for ISO
- 8473", Internet Draft, October 1992. DDN Network Infor-
- mation Center, SRI International.
-
- [4] ISO/IEC DIS 10747 Information Processing Sys-
- tems - Telecommunications and Information Exchange
- between Systems - Protocol for Exchange of Inter-domain
- Routeing Information among Intermediate Systems to Support
- Forwarding of ISO 8473 packets.
-
- [5] RFC 1238 CLNS MIB (Greg Satz) - for use with Connec-
- tionless Network Protocol (ISO 8473) and End system to
- Intermediate System Protocol (ISO 9452)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- March 23, 1993 Expires September 23, 1993 Page 14
-